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(57) Abstract 



An electronic file management system enables virtual read access to files (30) in a configuration directory (24) by effectively accessing 
actual copies of such files (32, 34, 36) in a repository directory (26) using symbolic referencing between the directories (40). User-defined 
symbolic references specify whether static or dynamic linking is established. 
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DISTRIBUTED FILE SYSTEM PROVIDING TRANSPARENT DATA MANAGMENT 

BACKGROUND OF THE INVENTION 

5 

1. Field of the Invention 

The invention relates generally to the field of 
distributed processing and storage systems, particularly 
to methods for improving data management in such 
10 distributed systems. 

2. Description of Background Art 

Design of electronic systems through the use of 
computer-aided design (CAD) software has and continues 

15 to have a dramatic increase in complexity associated 
with exponential increases in the size and number of 
data files, number of people involved, and design tools 
from an increasingly varied set of design tool vendors- 
There is tremendous pressure to reduce design cycle 

20 times, while the complexity of the designs also 

increases exponentially. Management of the versions of 
the computer files representing these designs must now 
be automated given the current and increasing complexity 
(beyond the ability to cope via manual methods) . 

25 

The standard approach to this problem is to 
create a database to represent all of this information, 
define and store a complex model of all the data files 
in that database, create a programming interface to 
30 access the information in the database, and copy files 
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out of the system when tools need to access the files. 

The problems with this approach are increasing 
system complexity to the point that nobody can 
5 understand the system as a whole, performance problems 
as additional tools and users attempt to access the 
database (s), the inability to integrate all the design 
tools into the design management system, and the lack of 
a simple, well-defined method for using the system to 
10 achieve the desired result. Further, the ability to 
customize these systems is very low. 



SUMMARY OF THE INVENTION 

15 

The invention resides in an electronic file 
management system having at least one processor and 
corresponding storage device wherein a configuration and 
repository directory are provided, such that a first 

20 symbolic reference in the configuration directory links 
to the repository directory, and a second symbolic 
reference in the configuration directory links through 
the first symbolic reference to a file in the repository 
directory. Thus, access of the file in the 

25 configuration directory effectively accesses the file in 
the repository directory. 

Preferably, the invention defines a software- 
implemented method for utilizing the decentralized 
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facilities provided through distributed storage on a 
computer network made available by distributed file 
system constructs combined with a prescribed method for 
using the system to track and process changes made by 
5 design engineers, for example, in designs of electronic 
systems and to combine and integrate those changes into 
a coordinated set of files that define a consistent 
state of the electronic system for release to other 
organizations, including manufacturing groups, both in 
10 local and remote physical locations. 

Through this invention, complex electronic 
systems can be designed by a larger number of engineers, 
than otherwise possible without the system, requiring 

15 less training of the engineers and less diversion from 
actual design work, on a distributed network of 
computers, without undue hardship created by the failure 
from time to time of portions of the computer network or 
computers on the network, utilizing the latest and most 

20 advanced design tools without any special integration 
requirements . Designs developed by many engineers can 
be more easily and accurately assembled into complete 
and consistent systems. The system is easily customized 
to optimize the methodology used to assemble electronic 

25 systems . 
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BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a generalized block diagram of a 
system according to the present invention. 

FIG. 2 is a simplified flow chart of a method 
according to the present invention. 



10 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

. FIG. 1 shows a general block diagram of 
electronic file management system having one or more 
processor-based 16, 18 nodes, systems or engineering 
15 workstations 10, 12, which may be networked 14 using 

conventional techniques to other such nodes. Each node 
10 , 12 includes conventional storage devices 20, 22, 
such as semiconductor and/or disk-based digital memory 
units. 

20 

Preferably, node 10 serves as designer 
workstation, and node 12 serves as project manager 
workstation, in the context of a distributed engineering 
data system for managing electronic design, particularly 
25 managed object configurations or file sets in a given 

project. Thus, nodes 10, 12 may also include in storage 
20, 22 an operating system, such as UNIX or VMS, and 
various computer-aided engineering and design (CAE/CAD) 
software tools, for example, for circuit schematic 
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capture, logic synthesis, digital or analog simulation, 
system layout, test vector generation, design 
documentation, database management, etc. 

5 It is contemplated that nodes 10, 12 may be 

configured, nonetheless, in the context of other 
distributed software applications, particularly where 
complex projects give rise to the generation and 
management of a large number of files or directories 
10 located at multiple storage sites. 

Further, it is contemplated that optional nodes 
10 1 , 12 1 having corresponding parts such as processors 
16 1 , 18 1 , storages 20 ■ , 22 ' , configuration and 

15 repository directories 24', 26*, and so on, are 

distributed across and networked 14 to the system. 
Thus, as used herein, the apostrophe (■) associated with 
a reference number represents corresponding parts for 
optional implementations, such as nodes 10*, 12' which 

20 are functionally equivalent to primary parts 
corresponding in nodes 10, 12. 

In accordance with the present invention, an 
electronic file management system or technique enables 
25 object or file access by an external software program or 
other user tool from one to another (or the same) 
directory, in a flexible and transparent manner. 
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In particular, using conventional operating 
system commands, a first or "configuration" storage 
portion or directory hierarchy 24 is provided 42, 
preferably in storage 20 of design node 10, and a second 
5 or "repository" storage portion or directory hierarchy 
26 is provided 42, preferably in storage 22 of project 
node 12, as shown in the simplified flow chart of FIG. 
2. Directories 24, 26 may be provided in the same node 
or may be a common directory. (See Appendix-A for 
10 simplified sample for directory creation.) 

Optionally, a third "shadow" storage portion or 
directory 26* is similarly provided, including the same 
file information and directory structure included in 
15 repository directory 26. In this way, fault tolerance 
and data redundancy is provided in case repository 
directory 26 becomes corrupted or inaccessible. 

Next, first symbolic reference or link file 40 
20 is provided 44, within configuration directory 24, which 
defines a direct, virtual data coupling, preferably from 
repository link file 27 provided in configuration 
directory 24, to repository directory 26. Preferably, 
at any given moment, the repository link in 
25 configuration directory 24 is linked symbolically to 
only one repository directory 26. 

As used herein, a symbolic reference or "link" 
is a file system special file type that points or refers 
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to another named file or object. Such links can span 
multi-processor or storage device file systems and point 
to files, directories or other links provided therein. 
The named file or object to which a link points is 
5 indicated by link contents, which include file system 
path name to the file or object to which such link 
points. Thus, when an operating system operation (e.g., 
read, write, close, open, etc.) is applied to a link, 
such operation effectively acts on the file to which the 
10 links points. 

Preferably, symbolic reference 40 is provided in 
network or global name space or path name. A network 
path name is a file system path name that, when used on 

15 one computer or node, results in access of a file or 

object that resides on another computer or node coupled 
thereto. Additionally, a global path name is a network 
path name that can be used on each computer or node 
coupled to a network (e.g., local or wide area), which 

20 resolves to a common file on one of such computers. 

Then, at least one managed object or data file 
32, preferably identified initially as "file,l w , is 
provided 46 or copied into repository directory 26 or 
25 sub directory thereunder. As described herein, a file 
set having more than one version of file 32 may be 
provided 46 therein. A "managed object" may be composed 
of many files 32, 34, 36 and optional additional files 
32' contained in the repository directory 26. Files 
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that make up a managed object may have paths of the 
form: <data-file path> , <managed object extensions The 
"managed object extension" is a unique string added to 
the names of the files composing the managed object 32, 
5 34, 36 stored in the repository directory 26, in order 
to uniquely distinguish them from each other. (See 
Appendix-B for simplified sample of managed object 
creation . ) 

10 Preferably, file 32 is provided 46 in repository 

directory 26 initially by providing such file 32, as 
"file" 30, in configuration directory 24, possibly 
generated from external program or tool. Versions of 
file 30, each version having a unique, positive non-zero 

15 integer managed object extension and possibly containing 
different information, may be created using the check- in 
process, for instance, when user checks out files for 
editing and then returns edited file versions therein. 
At check-in, a corresponding link file 28 is created for 

20 the version created of file 30. 

To provide each version of file 32 in repository 
directory 26, file 30 is copied from configuration 
directory 24 to repository directory 26; then, file 30 
25 is deleted from configuration directory 24. In this 

way, link 28, having the same file name as deleted file 
30, may be provided in configuration directory 24 to 
refer symbolically to copied file 32 in repository 
directory 26 through link 40, as described further 
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herein. 

Optionally, associated text file 34 related to 
file 32 is provided, preferably identified as 
5 "file, @info" , in the same directory or sub directory 

where file 32 is provided. Preferably, associated file 
34 is provided for each managed object or file 32, 
including information thereof, such as version history, 
properties, status, user descriptions, check-out/in, 
10 etc. For example, file 34 is updated with version 
number reserved by a check-out operation or version 
number from which a new managed object is created by an 
initial checkin operation. 

15 Preferably, file 32 is provided with a unique 

file name, which relates to a name assigned to 
corresponding file 28, 30 defined by user or tool. In 
this way, more than one version of file 32 may be stored 
in repository directory 26, and the system may detect 

20 when more than one file 32 is provided 46 with the same 
file name into repository directory or sub directory 
thereunder . 

As described herein, check- in operation is the 
25 mechanism which saves current state of file 30 within 

repository directory 26. (See Appendix-C for simplified 
sample of check-in process.) In particular, this 
operation is done by copying contents of file 30 into a 
managed object version file 32 within repository 
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directory 26. After copying file 30 into version file 
32, operating system access permissions of version file 
32 are set not to allow additional modification of 
version file contents. This restriction is done to 
5 preserve contents as they were when check-in operation 
was performed. 

Additionally, the copy of data file within 
configuration directory 24 is deleted and replaced by a 

10 symbolic reference, known as the managed object 

reference 28 to managed object version into which file 
30 was copied 32. The managed object version into which 
file 30 is copied must have been created by checkout- 
for-write operation, or never have been checked in 

15 before, as described herein. The same user performs 

both checkout- for-write and check- in operations because 
version to copy data file into is determined by which 
version file was checked out by user performing check- 
in. Preferably, this determination is done by examining 

20 contents of managed object's w co.<user-name>" link. 

If there is no version file checked out by the 
user performing the check- in operation, such operation 
will fail, and an error is reported. After successfully 
25 copying file 30 into version file 32, the managed 
object's n co.<user-name>" link is removed from 
repository directory 26. Whenever file 30 is checked in 
to managed object version file 32 by check- in operation, 
contents of managed object's n ©current" link 3 6 is 
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modified to point to version file 32. This modification 
causes dynamic Managed Object References to the managed 
object to refer automatically to newly checked- in 
version. 

5 

Check- in operation requires three pieces of data 
on which to operate: (1) configuration directory path 
24, (2) file 30 path within configuration directory 24 , 
and (3) binding type specification. Configuration 

10 directory path identifies configuration directory 24 and 
repository directory 26 , via configuration directory's 
repository link 27, which check- in operation is to use; 
data file path identifies which data file is to be 
operated on; and binding type specification indicates 

15 what type of managed object reference to create. 



The act of performing check- in operation on file 
30 is termed "checking the data file in" and after 
completion, such data file is said to have been "checked 

20 in." Check- in operation does not operate on managed 
object references (such as 28) . Performing check- in 
operation on data file twice in a row is not permitted 
because the first check- in operation replaces data file 
with managed object reference. Note that checkout- for- 

25 write operation may remove managed object reference, 

thereby replacing such reference with writable copy of 
one of managed object's version files. 
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Further, second symbolic reference or link file 
28 is provided 48, which defines a direct, virtual data 
coupling through, or which includes effectively, 
5 symbolic reference 40 to file 32. This second symbolic 
reference is termed a "Managed Object Reference. " 
Preferably, symbolic reference 28 is provided in local 
name space in configuration directory 24 or sub 
directory therein, according to user-defined link 
10 specification or binding type, which indicates type of 
symbolic reference 28. 

Two types of reference to managed object file 32 
can be defined by link 28. One type of reference is 
15 termed "static." A static reference is one in which 
link 28 includes path to link 40 and then the path to 
file 32 directly within repository directory 26. 

Another type of reference is termed "dynamic." 

20 To provide a dynamic reference, third symbolic reference 
or link file 36 is created in repository directory 26 
which includes path 38 to file 32. Preferably, link 36 
is identified as "file, ©current" and serves to determine 
which version file is referenced by dynamic managed 

25 object reference. Further, to provide such dynamic 

reference, link 28 includes path to link 40 and path to 
link 36 within repository directory 26. Thus, when read 
operation 50 on link 28 is performed (e.g., by external 
program or tool,) the effective result of read operation 
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50 is the same, such that content of file 32 is read. 

Hence, by changing the file to which link 28 
references, the file referenced may be redefined. For 
5 example, in a static case, link 28 must be changed to 

refer to a different file, other than file 32, such that 
link 28 points to another version of file 32, preferably 
provided in repository directory 26 or sub directory 
therein. 

10 Additionally, in a dynamic case, either link 28 

or link 36 may be changed to achieve the same result 
(i.e., accessing a particular version of file 32). For 
example, link 36 may be caused to refer to version-X of 
file 32, without changing content of link 28, but 

15 effectively changing the file to which link 28 points. 
Thus, dynamic referencing allows link 28 to be fixed 
once and then remain unchanged, while permitting the 
file to which accessing is performed to be changed by 
changing link 36. Note that during the file check-in 

20 process, content of link 36 may be changed to point to 
most recently-created file version. 

Preferably, managed object references contain 
three path name components : (1) reference to repository 
25 link 27, (2) directory portion of path to file 32, and 
(3) file name of one of managed object files for data 
file. In particular, the repository link reference 
portion is a "relative path" from the directory that the 
managed object reference is in to the repository link 
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for configuration directory 24. Because of how symbolic 
links function, this relative path allows contents of 
the managed object reference to determine the particular 
repository directory 26 to which the managed object 
5 reference refers. When the managed object reference and 
repository link are in the same directory, this portion 
merely contains the name of repository link. 

Moreover, the managed' object file name component 
10 that is selected depends on type of managed object 

reference. Hence, in the case of static managed object 
references, the file name selected is the managed object 
version corresponding to the version specified in the 
configuration reference. Preferably, such static 
15 references always refer to the same managed object 
version. 

In the case of dynamic managed object 
references, the file name selected is the managed 
20 object's "©current" symbolic link. As described further 
herein, such dynamic links enable the managed object 
version selected to be controlled by 
contents of managed object's "©current" link. 

25 Optionally, an other storage portion or 

configuration directory 24 1 is provided, on any node 10 1 
on system network 14, which may include information 
different from that included in- primary configuration 
directory 24. In this implementation, .third symbolic 
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reference or link 40* is provided, which defines a 
direct, virtual data coupling from the Repository Link 
27' in the other configuration directory 24', or sub 
directory thereunder, to repository directory 26, or sub 
5 directory thereunder- In this way, fourth symbolic 

reference 28' provided in corresponding storage 20 1 of 
other node 10' similarly links file 32 or other version 
of^Eiie 32' or version of different file 32, 34 provided 
in repository directory 26 through, or which includes 
10 effectively, symbolic reference 40*. 

Additionally, an other repository storage 
portion or directory 26 1 may be provided, on any node 
^12 1 on system network 14, which may include information 

15 different from that included in primary repository 

directory 26. In this implementation, fifth symbolic 
reference or link 40 1 is provided, which defines a 
direct, virtual data coupling from the Repository Link 
27" in the configuration directory 24, or sub directory 

20 thereunder, to other repository directory 26* , or sub 
directory thereunder. In this way, sixth symbolic 
reference 28* provided in storage 20' of design node 10 1 
similarly links an other object or file 32' provided in 
other repository directory 26* through, or which 

25 includes effectively, symbolic reference 40*. 

After symbolic reference 28 is provided 48, file 
v j, A 32 may be accessed through such symbolic reference 28 to 
perform read operation 50. Symbolic Reference 28 is 
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created preferably through checkout-f or-read process 
which provides a reference to the read-only copy of file 
32. Alternately, any tool or user program may now 
access file 32 through Symbolic Reference 28 withouth 
5 knowing its version or true location. (See Appendix-D 
for simplified sample of check-out process for read.) 

Preferably, checkout-f or-read operation is used 
to create managed object reference in configuration 
10 directory 24. As described further herein, such 

operation requires three pieces of information on which 
to operate: (1) configuration directory path, (2) data 
file path within configuration directory, and (3) 
binding type specification. 

15 

In particular, configuration. directory path 
identifies configuration directory 24 and repository 
directory 26 via configuration directory's repository 
link 27, on which checkout-f or-read operation will 
20 operate. Additionally, data-file path identifies which 
managed object the managed object reference is for, and 
binding type specification indicates what type of 
managed object reference to create. 

25 Optionally, version specification is provided 

for use when static binding type is specified. If 
dynamic binding type is specified and version 
specification is provided, version specification is 
ignored because dynamic managed object reference points 
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to n ©current" link and not a specific version. 

No modification of a managed object's files is 
performed by checkout- for-read operation. This 
5 restriction is done explicitly to allow users to perform 
checkout- for-read operation on managed objects which 
they may not be able modify, because of operating system 
access restrictions. The act of performing checkout- 
for-read operation on a data file may be termed 
10 "checking the data file out for reading" and after 

completion, data file may be said to have been '" checked 
out for reading . " 

Checkout- for-read operation does not operate if 
15 there is a writable copy of data file in specified 

configuration directory 24. This restriction is done to 
prevent accidental loss of data by unintentional use of 
checkout- for- read operation. If this situation is 
encountered, such checkout operation will fail, and 
20 error is reported. In any other situation, checkout- 
for-read operation will remove any copy or managed 
object reference for data-file in configuration 
directory 24 and replace it with specified managed 
object reference. 

25 

Alternately, to perform write operation 52, file 
32 is copied, preferably using a checkout- for-write 
process to generate a modifiable or writable file copy 
in configuration directory 24 or a sub-directory 
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thereof. Such checkout process is used to create a 
modifiable (i.e., "checked- out" ) managed object version 
file for the user performing write operation 52: (See 
Appendix-E for simplified sample of check-out process 
5 for write. ) 

In particular, an existing managed object 
version, which cannot be modified ordinarily, is copied 
to create another checked-out version, which is 

10 modifiable. Also, a managed object check-out link, 
which records which version was checked-out, may be 
created by user performing such check-out operation. 
This link is usable during check- in to determine into 
which managed object version file the writable file is 

15 to be copied. 

If the user performing a check-out for write 
operation already has a checked-out version of the 
managed object, then such operation fails, and error is 
20 reported. Preferably, each user may check out one 
version at a time of a managed object. 

The checkout- for-write operation requires three 
pieces of information on which to operate: configuration 
25 directory 24 path, data file path within configuration 
directory 24, and version selection option. 
Configuration directory path identifies conf iguration 
directory 24 and repository directory 26, for example, 
via configuration directory's repository link 27, 40, on 
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which such operation operates. Data file path 
identifies managed object on which to operate, and 
version selection option identifies how version to copy 
is selected. 

5 

There are three different version selection 
options which may be specified: (1) Current: this option 
indicates that version to be copied should be the 
version pointed at by the managed object " ©current " 

10 link. (2) Reference: this option indicates that version 
to be copied should be the version pointed at by the 
managed object reference for data file in configured 
directory 24. (3) Version <version_number> : this option 
indicates that a version <version_number> is to be 

15 copied. If version <version_number> does not exist, then 
checkout-for-write operation fails and reports error. 

The checked out version is a modifiable copy of 
specified version 32, which is stored in configuration 

20 directory 24 as specified to checkout-for-write 

operation. Preferably, managed object's "©info" file 34 
is examined to find the largest version number -used to 
date for such managed object. The new version is 
assigned a version number which is one larger than that, 

25 and an entry for the newly created version is added to 
the n @info M file. 

The new n @info" file entry records version 
number of the newly created version and also records 
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which version number from which it was copied. These 
entries represent the version derivation history of 
managed object (i.e., which versions were created from 
which others) . 

5 

A managed object checkout symbolic reference or 
link file is created in repository directory 26 for the 
user performing checkout -for-write operation. This link 
is named "co. <user-name>" , where user-name is replaced 
10 by the name of users account on node running checkout- 
for-write operation. Contents of such link is the name 
of the newly created managed object version file. 
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Appendix A 

SIMPLIFIED SAMPLE OF CREATING A CONFIGURATION DIRECTORY 

ConfigDirPath = [Get Path to Configuration Directory] 
ReposDirPath = [Get Path to Repository Directory] 
5 RepositoryLinkName = w .raw_data" 

RepositoryLinkPath = Conf igDirPath/RepositoryLinkName 



if ( ConfigDirPath does not exist) { 
create directory ConfigDirPath 
10 if (error while creating) { 

print error 
quit 
} 

} 

15 if ( RepositoryLinkPath exists) { 

print "Error - ConfigDirPath is already a 
Configuration Directory 11 
quit 

} 

20 create symbolic link RepositoryLinkPath with contents 
ReposDirPath 

if (error while creating link) { 
print error 
25 quit 
} 



Done 
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Append^ B 

SIMPLIFIED SAMPLE OP CREATING A MANAGED OBJECT 

5 

ConfigDirPath = [Get ConfigDirPath] 

DataFilePath = [Get data file-path] 

ConfigDataFilePath - Conf igDirPath/DataFilePath 
RepositoryLinkName = ".raw_data" 
10 RepositoryLinkPath = ConfigDirPath/RepositoryLinkName 
DataFileName = filename portion of DataFilePath 

if (ConfigDirPath does not exist) { 

print "Error - Configuration Directory does not exist" 
15 quit 
} 

if (ConfigDataFilePath does not exist) { 

print "Error - ConfigDataFilePath does not exist" 
20 quit 
} 

if (RepositoryLinkPath does not eist) { 
print "Error - ..." 
25 quit 
} 

RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic link 
MOPath = RepositoryDirectoryPath/DataFilePath 
30 InfoPath = MOPath + ",@info" 
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5 



10 



if (InfoPath exists) { 

print "Error - MO already exists for DataFilePath" 
quit 

} 

if (MOPath exists and is a directory) { 

print "Error - DataFilePath is already Checked in as a Directory" 
quit 

} 

VersionPath = MOPath + ",1 B 



for all directories in MOPath { 

if (directory does not exist) { 
15 create directory 

if (error while creating) { 
print error 
quit 

} 

20 } 

} 

InfoRecord ="10" 
Open InfoPath for Write 
Write InfoRecord to InfoPath 
25 Close InfoPath 

Copy Conf igDataFilePath to VersionPath 
if (error) { 

print "Error = Unable to copy file" 
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quit 

} 

Change Access permission of VersionPath to non-modifiable 

5 

CurrentPath = MOPath + ©current " 
CurrentContents = DataFileName + 

Create Symbolic link CurrentPath with Contents CurrentContents 

10 

RepositoryLinkRelativePath = " B 

for each directory in DataFilePath { 

RepositoryLinkRelativePath = RepositoryLinkRelativePath + "../" 

} 

15 RepositoryLinkRelativePath = RepositoryLinkRelativePath + 
Repos i t oryLinkName 

if (BlindingType = STATIC) { 

MORContents = RepositoryLinkRelativePath + DataFilePath + ",1" 

20 } 

if (BlindingType = DYNAMIC) { 

MORContents = RepositoryLinkRelativePath + DataFilePath + 
n , ©current " 
} 

25 Delete Conf igDataFilePath 

Create symbolic link Conf igDataFilePath with contents MORContents 
Done 
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Appendix C 
SIMPLIFIED SAMPLE OF CHECK- IN PROCESS 

Conf igDirPath = [Get Conf igDirPath] 

5 DataFilePath = [Get data-file-path] 

BindingType = [Get BindingType value] 
ConfigDataFilePath = Conf igDirPath/DataFilePath 
RepositoryLinkName = " .raw_data" 

RepositoryLinkPath = Conf igDirPath/RepositoryLinkName 
10 DataFileName = filename portion of DataFilePath 

if (Conf igDirPath does not exist) { 

print "Error - Configuration Directory does not 
exist" 
15 quit 
} 

if (ConfigDataFilePath does not exist) { 

print "Error - ConfigDataFilePath does not exist" 
20 quit 
} 

if (RepositoryLinkPath does not exist) { 
print "Error - ..." 
25 quit 
} 

RepositoryDirectoryPath = contents of 
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RepositoryLinkPath symbolic link 

MOPath = RepositoryDirectoryPath/DataFilePath 

InfoPath = MOPath + ",@info" 

CheckoutPath = MOPath + ",@co." + <user-account-name> 

5 

if (InfoPath does not exist ) { 

print "Error - MO does not exist for DataFilePath" 
quit 

} 

10 

if (CheckoutPath does not exist) { 

print "Error - user <user> does not have 

DatafilePath checked out" 
quit 

15 } 



if (ConfDataFilePath does not exist) { 
print "Error - no file to checkin" 
quit 

20 } 

if (ConfigDataFilePath is a directory) { 

print "Error - cannot checkin a directory" 
quit 

} 

25 

CheckoutPathContents = read contents of CheckoutPath 
CheckedOutVersion = [parse version number from 
CheckoutPathContents ] 

VersionPath = MOPath + "," + CheckedOutVersion 
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Copy ConfigDataFilePath to VersionPath 
Set OS access permissions of VersionPath to non- 
modifiable 

5 

CurrentPath » MOPath + " , ©current " 
CurrentContents = DataFileName + " , " + 
CheckedOutVer s ion 
delete CurrentPath 
10 create symbolic link CurrentPath with contents 
CurrentContents 



RepositoryLinkRelativePath = 
for each directory in DataFilePath { 
15 RepositoryLinkRelativePath = 

RepositoryLinkRelativePath + "../" 
} 



RepositoryLinkRelativePath = RepositoryLinkRelativePath 
20 + RepositoryLinkName 

if (BindingType = STATIC) { 

MORContents = RepositoryLinkRelativePath + 
DataFilePath + " , w + CheckedOutVersion 
} 

25 

if (BindingType = DYNAMIC) { 

MORContents = RepositoryLinkRelativePath + 
DataFilePath + ",@current" 
} 
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Delete Conf igDataFilePath 

Create symbolic link Conf igDataFilePath with contents 
MORContents 

5 

delete Checkout Path link 
Done 

10 
15 



20 
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Appendix p 

SIMPLIFIED SAMPLE OF CHECK-OUT FOR READ OPERATION 

Conf igDirPath = [Get Conf igDirPath] 

5 DataFilePath = [Get data-file-path] 

BindingType = [Get BindingType] 
ConfigDataFilePath = Conf igDirPath/DataFilePath 
RepositoryLinkName = " .raw_data" 

RepositoryLinkPath = Conf igDirPath/RepositoryLinkName 
10 DataFileNante = filename portion of DataFilePath 

if (Conf igDirPath does not exist) { 

print "Error - Configuration Directory does not 
exist" 
15 quit 

} J 

if (ConfigDataFilePath is a writable file) { 

print "Error - ConfigDataFilePath is writable, this 
20 operation will 

not overwrite it" 

quit 

} 

25 if (RepositoryLinkPath does not exist) { 
print ■ Error - ..." 
quit 

} 
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RepositoryDirectoryPath = contents of 
RepositoryLinkPath symbolic link 
MOPath = RepositoryDirectoryPath/DataFilePath 
InfoPath = MOPath + ",@info w 

5 

if (InfoPath does not exists) { 

print "Error - MO for DataFilePath does not exist" 
quit 

} 

10 

if (MOPath exists and is a directory) { 

print "Error - DataFilePath is Checked in as a 

Directory" 
quit 

15 } 

RepositoryLinkRelativePath = ■■ 
for each directory in DataFilePath { 
RepositoryLinkRelativePath = 
20 RepositoryLinkRelativePath + ",./" 
} 

RepositoryLinkRelativePath = RepositoryLinkRelativePath 
+ RepositoryLinkName 

25 

if (BindingType = STATIC) { 

VersionNumber = [Get Version Number] 
if (no Version Number provided) { 
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CurrentPath = MOPath + ■ , ©current " 
CurrentContents = read contents of CurrentPath 
VersionNumber = Parse Managed Object Extension 
from CurrentContents 
5 } 

MORContents = RepositoryLinkRelativePath + 
DataFilePath + VersionNumber 

10 } 

if (BindingType = DYNAMIC) { 

MORContents = RepositoryLinkRelativePath + 
DataFilePath + " , Scurrent n 
15 } 

delete Conf igDataFilePath 

create symbolic link Conf igDataFilePath with contents 
MORContents 

20 
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Appendix E 

SIMPLIFIED SAMPLE OF CHECK-OUT FOR WRITE OPERATION 

ConfigDirPath = [Get Conf igDirpath] 

5 DataFilePath = [Get data-file-path] 

VersionSpec = [Get Version Specification] 

ConfigDataFilePath = Conf igDirPath/DataFilePath 

RepositoryLinkName = ".raw_data" 

RepositoryLinkPath » Conf igDirPath/RepositoryLinkName 

10 DataFileName = filename portion of DataFilePath 

if (ConfigDirPath does not exist) { 

print "Error - Configuration Directory does not exist" 

quit 

} 

15 if (ConfigDataFilePath exists and is writable) { 

print "Error - ConfigDataFilePath is writable, this operation will 
not overwrite it" 

quit 

} 

20 if (RepositoryLinkPath does not exist) { 
print "Error - . . . ■ 
quit 

} 

RepositoryDirectoryPath = contents of RepositoryLinkPath symbolic 
25 link 

MOPath = RepositoryDirectoryPath/DataFilePath 
InfoPath = MOPath + ",@info" 
if (InfoPath does not exists) { 

print "Error - MO for DataFilePath does not 
30 exist" 
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} 

if (MOPath exists and is a directory) { 

print "Error - DataFilePath is Checked in as a Directory" 
5 quit 
} 

if (VersionSpec = Reference) { 

CurrentPath = MOPath + " , ©current " 

CurrentContents = read contents of 
10 CurrentPath 

VersionNumber = parse version number from CurrentContents 
} 

if (VersionSpec = Current) { 

if (ConfigDataFilePath is not a symbolic link) { 
15 print "Error - ConfigDataFilePath is not a Managed Object 

Reference" 
quit 

} 

MORContents = read contents of ConfigDataFilePath 
20 MORExten = parse MOR Contents for the Managed Object Extension 

if (error finding Managed Object Extension) { 

print "Error - ConfigDataFilePath is not a Managed Object 

Reference" 

quit 

25 } 

if (MORExten is "©current") { 

CurrentPath = MOPath + " , ©current " 
CurrentContents = read contents of CurrentPath 
VersionNumber = parse version number from CurrentContents 
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} else { 

7* MORExten must be a version number */ 
Vers i onNumber = MORExt en 

} 

5 } 

if (VersionSpec = Version) { 

VersionNumber = [Get Version Number] 

} 

CheckoutLinkPath = MOPath + ",@co. B + user account name 
10 if (CheckoutLinkPath exists) { 

print "Error - user <account name> already has DataFilePath 
checked out" 

quit 

} 

15 if (don f t have OS access permission to modify InfoPath file OR 
don't have OS access permission to create file in InfoPath 
directory) { 

print "Error - lack sufficient permission to checkout 
20 DataFilePath" 
quit 

} 

VersionPath = MOPath = " , ■ = VersionNumber 
if (VersionPath does not exist) { 
25 print " Error " 

quit 

} 

LargestVersion = 0 

Open InfoPath file for reading 
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for each Record in InfoPath { 

Parse record into RecordVersionNumber and RecordDerivedFromVersion 
if (RecordVersionNumber > LargestVersion) 
LargestVersion = RecordVersionNumber 

5 } 

NewVersionNumber = LargestVersionNumber + 1 

Construct Newlnf oRecord = NewVersionNumber + n " + VersionNumber 
Write NewInfoRecord to InfoPath 
for each directory in Conf igDataFilePath { 
10 if (directory does not exist) 

create directory 

} 

NewVersionPath = MOPath + ■ , 0 + NewVersionNumber 
CheckoutLinkContents = DataPileName + ° , " + NewVersionNumber 
15 if (ConfigDataFilePath exists) { 
delete ConfigDataFilePath 

} 

copy file VersionPath to ConfigDataFilePath 
set OS permissions of ConfigDataFilePath to modifiable 
20 create symbolic link CheckoutLinkPath with contents 
CheckoutLinkContents 
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We claim: 

1. A method for electronic file management 
comprising the steps of: 

5 providing a first and second directory; 

providing a first link in the first directory to 
the second directory; 

providing a first file in the second directory; 

and 

10 providing a second link in the first directory 

or a sub-directory thereunder through the first link to 
the first file. 

2. The method of Claim 1 wherein: 

15 the first and second directory comprise a common 

directory. 

3 . The method of Claim 1 further comprising the 

step of: 

20 providing a third directory that includes the 

same information as included in the second directory. 

4. The method of Claim 1 wherein: 
the first and second links comprise symbolic 
25 references . 



5 . The method of Claim 1 further comprising the 

step of: 

providing a fourth directory that includes 
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different information than included in the second 
directory; 

providing a third link in the first directory to 
the fourth directory; 
5 providing a second file in the fourth directory; 

and 

providing a fourth link through the third link 
to the second file. 

10 6. The method of Claim 1 wherein: 

the first file is provided in a sub directory 
tinder the second directory. 



7. The method of Claim 1 wherein: 

15 the second link is provided from a sub directory 

under the first directory. 

8. The method of Claim 1 further comprising the 

step of: 

20 providing in the second directory a third file 

associated with the first file. 

9. The method of Claim 8 wherein: 

the third file comprises version information 
25 about the first file. 

10. The method of Claim 1 wherein: 

the first file is provided with a first name, 
such that providing another file with the same name is 
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detectable . 

11. The method of Claim 1 wherein: 
a plurality of versions of the first file is 
5 provided in the second directory. 



10 



12. The method of Claim 1 wherein: 

the second link is provided according to a user- 
defined link specification. 

13. The method of Claim 12 wherein: 

the link specification indicates whether the 
second link is static or dynamic. 



15 14. The method of Claim 12 further comprising 

the step of: 

providing in the second directory a third link 
which refers to the first file. 

20 15. The method of Claim 14 wherein: 

the second link to the first file is provided 
also through the third link. 

16. The method of Claim 14 wherein: 

25 the second link refers to the third link to 

refer indirectly to the first file. 

17. The method of Claim 14 wherein: 

the second link is pointable either to the first 
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file in static mode or to the third link in dynamic 
mode . 

18. The method of Claim 14 wherein: 

5 the third link is modifiable to refer to an 

other file. 

19. The method of Claim 1 further comprising 
the steps of: 

10 providing a fifth directory; 

providing a fifth link in the fifth directory to 
the second directory; and 

providing a sixth link in the firth directory 
through the fifth link to the first file in the second 
15 directory. 

20. The method of Claim 1 further comprising 
the step of: 

accessing the first file through the second link 
20 to perform a read operation. 

21. The method of Claim 1 further comprising 
the steps of: 

deleting the second link; and 
25 copying the first file to the first directory to 

perform a write operation. 



22. The method of Claim 1 wherein: 

the first link is provided in a network name 
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space . 



23 . The method of Claim 1 wherein the step of 
providing the first file in the second directory 
5 comprises the following steps: 

providing the first file in the first directory; 

copying the first file from the first directory 
to the second directory; 

deleting the first file in the first directory; 

10 and 

providing the second link in the first directory 
to the copied first file in the second directory through 
the first link. 



15 24. The method of Claim 1 wherein: 

the second link is provided a link name which is 
identical to a file name provided to the first file. 



25. The method of Claim 1 wherein: 
20 the second link is provided with a link name 

which is identical to a file name provided to a copied 
file provided in the first directory, wherein the copied 
file is identical to the first file. 

25 26. A method for object management comprising 

the steps of: 

providing a configuration directory and a 
repository directory; 

providing a first symbolic reference in the 
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conf iguration directory to the repository directory; 

providing an object in the repository directory; 

and 

providing a second symbolic reference through 
5 the first symbolic reference to the object, wherein the 
second symbolic reference is provided according to a 
user-defined specification which indicates whether the 
second symbolic reference is static or dynamic. 

10 27. A method for electronic file management 

comprising the steps of: 

providing a configuration directory and a 
repository directory; 

providing a first symbolic reference in the 
15 configuration directory to the repository directory; 

providing a file in the configuration directory; 
copying the file from the configuration 
directory to the repository directory; 

deleting the file in configuration directory; 

20 and 

providing a second symbolic reference through 
the first symbolic reference to the file copy in the 
repository directory. 

25 28. The method of Claim 27 wherein: 

the second symbolic reference is provided 
according to a user-defined specification which 
indicates whether the second symbolic reference is 
static or dynamic. 
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29. An electronic file management system 
comprising: 

at least one processor unit, each processor unit 
having a corresponding storage device; 

a configuration directory in one of the storage 

units; 

a repository directory in one of the storage 

units; 

a first symbolic reference in the configuration 
directory to the repository directory; 

a file in the repository directory; and 
a second symbolic reference for linking through 
the first symbolic reference to the file; 
15 wherein an access to the file in the 

configuration directory effectively accesses the file in 
the repository directory. 



10 



20 



25 
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PROVIDE CONFIGURATION DIRECTORY 
AND REPOSITORY DIRECTORY 



PROVIDE SYMBOL 
CONFIGURATE 
REPOSITORY 


JC REFERENCE IN 
J DIRECTORY TO 
'DIRECTORY 




46 

<> 



PROVIDE OBJECT IN REPOSITORY 
DIRECTORY 



48 



jL 



PROVIDE SYMBOLIC REFERENCE TO 
BOJECT THROUGH INTER-DIRECTORY 
SYMBOLIC REFERENCE 



50 

jL 



52 



READ OBJECT 



o COPY FILE 
TO CONFIG. DIR. 

o WRITE OBJECT 
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